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^ (57) Abstract: A system and method is provided for collecting and transporting DTMF digits between two network end points in a 
® packet network in order to preserve the integrity of the DTMF digits. The system and method use a Session Initiation Protocol (SIP). 
O which is currently defined by the standaid body of Internet Engineering Task Force. SIP applications utilize certain predetermined 
^ messages, such as an INFO message, and templates. DTMF digits can be coUected and transported by using the SIP INFO messages. 
^ This works especially well for telephony applications which may require mid session signaling. 
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DTMF DIGIT COLLECTION AND TRANSPORTATION 
FOR A PACKET NETWORK 

Background of the Invention 

The present invention relates generally to telecommunication systems, and more 
particularly, to a system and method for collecting and transporting dual tone multi- 
frequency ("DTMF") digits through a packet network. 
5 Packet networks are often preferred over traditional circuit-switched communication 

networks because they provide speed, flexibility and efficiency for data communication. 
However, much of the hardware equipment currently in existence is designed for the circuit- 
switched communication networks such as the public switched telephone network 
("PSTN"). The coexistence of both types of networks creates many gaps between the 

10 technologies. Traditionally, a voice conversation and DTMF digits are transported together 
over the PSTN through a voice channel. Because the comparatively slow speed of 
traditional communication technology, the DTMF digits will be well preserved. 

DTMF digits are not always well preserved in a high speed packet network. Packet 
networks compress and embed information into small and numerous packets, and send the 

15 packets out with the expectation that all these packets will be appropriately received by 
another end point and assembled accordingly. However, it is inevitable that some 
information may not be recoverable by the receiving end point and thus lost in between the 
two end points. This is especially true when transferring DTMF digits in a voice channel 
over a packet network. Since a DTMF digit bears information of a relatively small size, it is 

20 more Ukely that the receiving end point cannot assemble packets to obtain a full 
comprehension of the sent tone. 

Therefore, what is needed is a system and method for collecting and transporting 
DTMF digits over a channel independent of the voice channel in order to preserve the 
integrity of the DTMF digits. 

25 Summary of the Invention 

A system and method is provided for collecting and transporting DTMF digits 
between two network end points in a packet network in order to preserve the integrity of the 
DTMF digits. In one embodiment, the present invention uses a Session Initiation Protocol 
(SIP), which is currently defined by the standard body of Internet Engineering Task Force. 
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Referring now to Fig. 1, a communication network system 10 including two SIP 
enabled end points is shown. When a SIP enabled end point A 12 initiates a SIP call setup 
message to be sent to an end point B 14, it starts a call session. Thereafter, other handshake 
messaging processes are completed to establish a voice path 16. Users at the two end points 

5 can then use the voice path 16 for exchanging voice information. Since the voice path is a 
packet network, voice information is encoded into a series of packets. System error may 
cause a loss of a small number of such packets in a high speed data exchange, but will not 
affect the overall quality of the voice information at the receiving end since sufficient 
information can be extracted from the received packets. While it may be acceptable to 

10 occasionally lose packets of voice information, it is often not acceptable to lose DTMF digits. 
However, collecting and transporting DTMF digits in packet form through the voice path 16 
increases the risk of losing the digits. 

In response to this problem, the present invention avoids the use of the voice path as 
a vehicle to transport the DTMF digits. Instead, the DTMF digits are collected and 

15 transferred in SIP messages. One such message is a SIP INFO message 18. An INFO 
message is a standard SIP message. However, in the present embodiment, the INFO 
message is used to collect and encode DTMF digits. Furthermore, the exchange of DTMF 
digits using INFO messages can be bi-directional, if needed. 

Fig. 2 illustrates the commimication network system 10 in accordance with another 

20 embodiment of the present invention showing communications exchanged between a SIP 
enabled end point A and a SIP enabled Requestor 20. After a SIP call is setup between the 
end point A and the Requestor, a voice path is established for a call session. Then the 
Requestor requests the end point A to collect mid session DTMF digits through an INFO 
message. The end point A collects the digits and sends them back to the Requestor through 

25 the INFO message as well. By doing so, the INFO message becomes a communication 
channel for DTMF digits. 

Fig. 3 illustrates a flow diagram showing steps taken by the end point A and the 
Requestor of Fig. 2 for collecting and transporting mid session DTMF digits. In step 22, the 
Requester sends a request for collecting mid session digits through the INFO message. In 

30 step 24, a Digit Map template is sent in the request to inform end point A to collect digits 
according to the instruction and format defined in the Digit Map. Once the Digit Map is 
received, end pomt A confirms its receipt through an INFO message in step 26. In step 28, 
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the end point A also checks a Digit Map Flag to see whether the received Digit Map should 
be stored for future use after the current Digit Map has been processed or used to 
immediately replace the Digit Map currently being processed. 

In one embodiment of the present invention, if the Digit Map Flag equals to 1, then, 
5 in step 30, the received Digit Map is stored to be used for collecting digits for the next round, 
otherwise, in step 32, the received Digit Map will be used immediately in replacement of the 
Digit Map on hand. Once an appropriate Digit Map is determined, end point A starts to 
collect mid session DTMF digits in step 34. After the collection is done, the collected digits 
are sent from end point A to the Requester in another INFO message in step 36. Upon 
10 receiving the newly collected digits, the Requestor confirms to end point A of such receipt 
through an INFO message in step 38. 

Fig. 4 illustrates a schematic of a commvmication network system 10 having SIP 
enabled equipment, traditional PSTN equipment, and a SIP-to-PSTN gateway. Due to the 
existence of the PSTN equipment, the above described mid session digit collection method 
L5 through the use of SIP technology must deal with non-SIP enabled PSTN equipment. In 

Fig. 4, a dotted line 40 artificially indicates a boundary between the SIP enabled portion and 
the PSTN portion of the communication network 10. A SIP-to-PSTN gateway 42 can be 
installed to assure smooth data flow between the two portions of the commimication 
network 10. On the SIP side of the network, there are "N" number of SIP enabled end 
20 points 12 that can be commimicating to the gateway 42 by using the voice channel and the 
INFO message channel. Once the gateway 42 receives all the collected DTMF digits, it then 
converts them and further transmits them through traditional PSTN voice path. 

For the purpose of describing the present invention, an example set of message 
syntaxes are defined as follows in one embodiment of the present invention: 
25 The Request message is formatted as specified in SIP RFC 2543 standard: 

Request = Request-Line 
*( general-header 
I request-header 
I Content-Encoding 
30 I Content-Length 

I Content-Type) 
CRLF 
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[ message-body ] 

wherein Request-Line = Method SP Request-URI SP SIP-Version CRLF; 
Method = "INFO" 

Content-Type = ("Content-Type" | "c") media-type 
5 media-tjrpe = "application/vnd.nortehietworks.digits" 

message-body = Package-Name CRLF Package-Type CRLF 
Package-Body CRLF 

Package-Name = ("Package-Name" | "p") Pkg-Name 
Pkg-Name = ("Digit-Collection" | token) 
.0 Package-Type = ("Package-Type" | "y") Pkg-Type 

Pkg-Type = ("DigitMap" | 'Digits" | "Cancel") 
Package-Body = ( Digitmap-Body | Digits-Body ) 

The Package-Name parameter provides a frame work to define different packages, 
therefore it is easy to add new types of information if needed, which makes the frame work 
.5 extensible. The Digit-Collection package includes three kinds of package types: (1) the 
DigitMap package type may include a Digitmap-Body; (2) the Digits package type may 
include a Digits-Body; and (3) the Cancel package type includes no Package-Body. 

The Digitmap-Body in the DigitMap message is a template for the digit collection. In 
the template, it specifies instructions and formats for the digit collection. The 
10 Digitmap-Body is sent by a Requestor in an INFO message with the Package-Type defined as 
DigitMap before any digits are collected. Upon receiving this message, a receiver such as the 
end point A in Fig. 2 should respond with a 200 OK message to confirm the receipt of the 
same and start collecting digits according to the Digitmap-Body (i.e., the template). Once 
collection is complete, end point A sends an INFO message having Digits as the 
J5 Package-Type and with the Digits-Body containing the collected digits. 

A valid Digitmap-Body includes one or more of the following fields that can be 
specified in any order: 

Digitmap-Body = Min-Digits CRLF 
Max-Digits CRLF 
JO Inter-Digit-Timer CRLF 

Last-Digit-Timer CRLF 
Total-Timeout CRLF 
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Termination-Key-Flag CRLF 
Termination-Key CRLF 
Repeat-Count CRLF 
Override CRLF 
5 Digit-Map-Association CRLF 

Inside the Digitmap-Body, the Min-Digits parameter defines the minimum number of 
digits to be collected. The Max-Digits parameter defines the maximum number of digits to 
be collected. The Termination-Key is not counted as either in the Min-Digits or the Max- 
Digits. The Inter-Digit-Timer parameter defines the maximum time that the system waits 
10 for the user between two key entries. The Last-Digit-Timer parameter defines the 

maximum time that the system waits for the user between two key entries. The Inter-Digit- 
Timer restarts after each key entry until the minimum number of digits (Min-Digits) have 
been collected, and the Last-Digit-Timer restarts after each key entry after the m i nimum 
number of digits (Min-Digits) have been collected. The value of both parameters may be 
15 specified in milliseconds. Further, the Total-Timeout parameter defines the total time that 
the system waits for a Max-Digits number of digits to be entered by a user. This timer is 
started when the digit collection process begins. 

In addition, the Termination-Key-Flag defines a boolean flag that determines 
whether the Termination-Key should be included at the end of digit-string in the 
20 Digits-body. This flag value is specified as 1 (true) or 0 (false). If the flag is set to true and 
the user enters the Termination-Key, then the Termination-Key is appended at the end of 
digit-string. Otherwise, it is disregarded. The Termination-Key parameter specifies a 
specific key that the user enters to terminate the digit stream. Common Termination-Keys 
include the "#" or the 

25 Since a Digit Map can be reused, the Repeat-Count parameter defines the additional 

number of times the current Digit Map will be used after it has been used once. A repeat 
coimt value of 0 indicates no repetition after the digit collection has been performed once. A 
repeat count value of 1 indicates one additional collection need to be performed after an 
initial digit collection has been performed, resulting in a total of two (2) collections. The 

30 Override parameter indicates whether the Digit Map contained in the message should 

replace the current Digit Map or to be stored to a list of Digit Maps. The Override value is 
specified as either 1 (replace) or 0 (stored). A request to replace the existing Digit Map will 
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be accepted only when no digit collection is in progress thus avoiding any interruption of 
active digit collection. 

The Digit-Map-Assodation field is used to tag the DigitMap message with a unique 
ID. Upon completion of the digit collection, the end point A may include the 
5 Digit-Map-Association ID from the DigitMap message to the Digits message. This allows the 
Requestor to synchronize Digit Maps with Digit messages it receives. 

In a message of Digits Package type, the Digits-Body contains the digits a iiser has 
entered along with some additional information about those digits. A valid Digits-Body 
includes one or more of the following fields that can be specified in any order: 
10 Digits-Body = Digit-String CRLF 

Termination-Key CRLF 
Termination-Key-Flag CRLF 
Playback-Tone-Duration CRLF 
Playback-Inter-Digit-Timer CRLF 
15 Digit-Status CRLF 

Digit-Map-Association CRLF 
Inside the Digits-Body, the Digit-String parameter holds the DTMF digits collected 
fi-om the user. The Termination-Key-Flag tells whether the Digit-String field contains a 
termination key. A "0" indicates the termination key is not included, while a "1" indicates 
20 that it is included. Similar to the DigitMap Package type, the Termination-Key specifies a 
key that the user can enter to terminate a digit stream. The Playback-Tone-Duration 
parameter tells the recipient how long (in milliseconds) to pulse the tone of each digit. And 
the Playback-Inter-Digit-Timer parameter tells the recipient 
how long (in milUseconds) to pause between pulsing two digits. 
25 Further, the Digit-Status field returns one of predefined labels describing the status 

of the message. The supported Digit-Status values are as follows: 
"success" - signifies that the Digit-String contains 
information that meets the requirements 
of the previously received DigitMap 
30 request. 

"inter-digit-timer-exp" - signifies that the Digit-String of the 
Digits message is not complete, as the 
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Inter-Digit-Timer has expired before the 

minimum number of digits were entered, 
"last-digit-timer-exp" - signifies that the Last-Digit-Timer has 

expired and the appUcation now has to 
5 determine the validity of the Digit-String 

as it may or may not be complete, 
"total-timer-exp" - signifies that the Total-Timer has 

expired and the application now has to 

determine the validity of the Digit-String 
10 as it may or may not be complete. 

*'imsolicited-digits" - signifies that the message was tmsolidted 

(i.e., not resulting from a Digit Map 

request) 

Similar to the DigitMap Package type, the Digit-Map-Association field is used to tag 
15 the Digits message with a unique ID. 

Another type of message is a Cancel message, which is sent by the Requester to 
indicate that it would like to cancel the previous Digit Map message already sent. 
Immediately after receiving a Cancel message, the end point A cancels all pending digit 
collections based on the specified Digit Maps received earlier and stops the process of 
20 collecting any digits. Upon receiving this message, the client should respond with a 200 OK, 
to confirm the receipt of this Cancel message. 

For clearly explaining the details of the present invention, a sample is given below to 
illiistrate the communication between the Requester and the SIP enabled end point A. 

Assuming that the Requester requests an accotmt number from end point A, and the 
25 nxunber is between 5 to 7 digits. It is to be terminated with a "#" which may be included in 
the digit message. Inter-Digit-Timer is set at 5 seconds, the Last-Digit-Timer is set at 4 
seconds, and the Total-Timer is set to 45 seconds. For the sample shown below, the term 
"CUenf* is referred to the end point A. 

First, the Requester sends a DigitMap request to the Client using SIP INFO message. 
30 The message body is shown as follows: 

INFO sip:Client@47.161.18.26:5060 SIP/2.0 
Via: SIP/2.0/UDP 47.161.18.122 
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To: sip:Client@nortelnetworks.com ;tag=615145584 
From: sip:Requester@nortelnetworks.com 
Call-ID: 1246884437@nortelnetworks.com 
CSeq: 2 INFO 

5 Content-Type: application/vnAnortelnetworks.digits 

Content-Length: 75 
p = Digit-Collection 
y=DigitMap 
m=5 

10 n=7 

i=5000 
1=4000 
t=45000 
k=# 

15 f=l 
r=0 
0=0 

8=3452985896 

Then, end point A confirms the receipt of the DigitMap message by a 200 OK message as 
20 shown below: 

SIP/2.0 200 OK 

Via: SIP/2.0/UDP 47.161.18.122 
To: sip: Client@nortehietworks.com ;tag= 615145584 
From: sip:Requester@nortelnetworks.com 
25 Call-ID: 1246884437@nortelnetworks.com 

CSeq: 2 INFO 
Content-Length: 0 

Next, the Client will collect digits based on the received Digit Map. Upon 
completion of a successful digit collection, the Client sends a Digits message to the 
30 Requester containing the collected digits. The message reads as follows: 
INFO sip:Requester@47.161.18.26:5060 SIP/2.0 
Via: SIP/2,0/UDP 47.161.18.122 
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To: sip:Reqiiester@nortelnetworksxom ;tag= 615145584 
From: sip:Client@nortelnetworks.coin 
Call-ID: 1246884437@nortebietworks.com 
CSeq: 3 INFO 

Content-Type: application/vnd.nortelnetworks.digits 

Content-Length: 55 

p=Digit-Collection 

y=Digits 

d=:123456# 

k=# 

f=l 

s= success 
a=3452985896 

The following INFO message would be sent from end point A to the Requester in the 
event that the Inter-Digit-Timer expires before the minimum number of digits have been 
collected. 

INFO sip:Requester@nortelnetworks.com:5060 SIP/2.0 
Via: SIP/2.0/UDP 47.161.18.122 

To: sip:Requester@nortelnetworks.com ;tag=615145584 
From: sip:Client@nortelnetworks.com 
Call-ID: 1246884437@nortelnetworks.com 
CSeq: 3 INFO 

Content-Type: application/vnd.nortelnetworks.digits 

Content-Length: 57 

p = Digit-Collection 

y= Digits 

d=123 

s =inter-digit-timer-exp 
a=3452985896 

Immediately thereafter, the Requester confirms the receipt of Digits message with 
the following message: 

SIP/2.0 200 OK 
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Via: SIP/2.0/UDP 47.161.18.122 
To: sip:Client@nortelnetworks.coin ;tag=615145584 
From: sip:Requester@nortelnetworks 
Call-ID: 1246884437@nortelnetworks.com 
5 CSeq:3INF0 

Content-Length: 0 

In order to cancel digit collection, the Requester sends the following message to 

cancel the Digit Map: 

INFO sip:Client@47.161.18.26:5060 SIP/2.0 
10 Via: SIP/2.0AJDP 47.161.18.122 

To: sip:Client@nortelnetworks.com ;tag=615145584 
From: sip:Requester@nortelnetworks.com.com 
Call-ID: 1246884437@nortelnetworks.com 
CSeq: 3 INFO 

15 Content-Type: application/vnd.nortelnetworks.digits 

Content-Length: 30 
p = Digit-Collection 
y= Cancel 

whereas end point A confirms the receipt of the Cancel message with the following message: 
20 SIP/2.0 200 OK 

Via: SIP/2.0/UDP 47.161.18.122 ^ 

To: sip:Client@nortelnetworks.com ;tag=615145584 

From: sip:Requester@nortelnetworks 

Call-ID: 1246884437@nortelnetworks.com 
25 CSeq: 3 INFO 

Content-Length: 0 

While the invention has been particularly shown and described with reference to the 
preferred embodiment thereof, it will be understood by those skilled in the art that various 
changes in form and detail may be made therein without departing from the spirit and scope 
30 of the invention, as set forth in the following claims. 
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Claims 

WHAT IS CLAIMED IS: 

1. A method for collecting and transporting one or more mid session digits 
through a packet communication chaimel between two end points in a telecommunication 
system, the method comprising the steps of: 

encoding the mid session digits in an INFO message whose format is defined by a 
5 Session Initiation Protocol; and 

exchanging the encoded mid session digits through the packet communication 
channel independent of a packet communication channel for exchanging voice information. 

2. A method for coUecting and transporting one or more mid session digits 

10 through a packet communication channel between a first end point and a second end point 
in a telecommxmication system, the method comprising the steps of: 

sending a request for collecting the mid session digits firom the first end point to the 
second end point; 

providing a template by the first end point to the second end point including digit 
15 collection format and instructions; 

collecting the mid session digits by the second end point according to the digit 
collection format and instructions provided in the template; and 

sending the collected mid session digits from the second end point to the first end 

point, 

20 wherein all the above commxmications between the first and the second end points 

are through one or more INFO messages conforming to a Session Initiation Protocol (SIP). 

3. The method of claim 2 further comprising a step of confirming the receipt of 
the template by sending an INFO message from the second end point to the first end point. 

25 

4. The method of claim 2 further comprising a step of determining an immediate 
use of a digit map in the template for the digit collection. 
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5. The method of claim 4 wherein the step of determining includes one of either 
storing the digit map for a next roimd of digit collection or replacing any existing digit map 
received by the second end point. 

5 6. The method of claim 2 further comprising a step of confirming the receipt of 

the collected digits by an INFO message from the first end point to the second end point. 

7. The method of claim 2 further comprising the steps of: 
converting the collected digits into a format acceptable for transmission in a 

10 predetermined communication channel not configured for the SIP standard. 

8. The method of daim 2 further comprising a step of sending a cancel message 
in an INFO message to terminate any active digit collection. 

15 9. A method for collecting and transporting one or more mid session digits 

through a packet conununication channel between a first and a second end points in a 
telecommunication system, the method comprising the steps of: 

sending a request for collecting the mid session digits from the first end point to the 
second end point; 

20 providing a template by the first end point to the second end point including digit 

collection formats and instructions; 

confirming the receipt of the template by the second end point; 
determining an immediate use of a digit map in the template for the digit collection; 
collecting the mid session digits by the second end point according to the digit 
25 collection format and instructions provided in the template; 

sending the collected mid session digits from the second end point to the first end 
point; and 

confirming the receipt of the collected digits by the first end point, 
wherein all the above communications between the first and the second end px)ints 
30 are through one or more INFO messages conforming to a Session Initiation Protocol (SIP). 
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10, The method of claim 9 wherein the step of determining further includes one of 
either storing the digit map for a next round of digit collection or replacing any existing digit 
map received by the second end point. 

5 11. A system for collecting and transporting one or more mid session digits 

through a packet commimication channel between a first and a second end points in a 
telecommunication system, the system comprising: 

a first subsystem for collecting the mid session digits sent from the first end point to 
the second end point; 
10 a template including digit collection format and instructions; 

a second subsystem for collecting the mid session digits by the second end point 
according to the digit collection format and instructions provided in the template; and 

a third subsystem for sending the coDected mid session digits from the second end 
point to the first end point, 
15 wherein both the first and the second end points are configured for applications using 

a Session Initiation Protocol (SIP) and all communications between the two end points are 
through one or more INFO messages conforming to the SEP standard. 

12. The system of claim 11 further comprising a fourth subsystem for confirming 
20 the receipt of the template by the second end point. 

13. The system of claim 11 further comprising a fourth subsystem for 
determining an immediate use of a digit map in the template for the digit collection. 

25 14. The system of claim 13 wherein the fourth subsystem for determining further 

includes one of either a fifth subsystem for storing the digit map for a next roimd of digit 
collection or a sixth subsystem for replacing any existing digit map received by the second 
end point. 

30 15. The system of claim 11 further comprising a fourth subsystem for confirming 

the receipt of the collected digits by the first end point. 

15 
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16. The system of claim 11 further comprising a fourth subsystem for converting 
the collected digits in the INFO message into a format acceptable for transmission in a 
predetermined communication channel not configured for the SIP standard. 

5 17. The system of claim 11 further comprising a fourth subsystem for sending a 

cancel message in an INFO message to terminate any active digit collection. 

18. A system for collecting and transporting one or more mid session digits 
through a packet communication channel between a first and a second end points in a 

10 telecommunication S3^stem, the system comprising: 

a request message for collecting the mid session digits sent from the first end point to 
the second end point; 

a template including digit collection formats and instructions; 
means for confirming the receipt of the template by the second end point; 
15 means for determining an immediate use of a digit map in the template for the digit 

collection; 

means for collecting the mid session digits by the second end point according to the 
digit collection format and instructions provided in the template; 

means for sending the collected mid session digits from the second end point to the 
20 first end point; and 

means for confirming the receipt of the collected digits by the first end point, 

wherein both the first and the second end points are configured for applications using 
a Session Initiation Protocol (SIP) and all communications between the first and the second 
end points are through one or more INFO messages defined by the SIP. 

25 

19. The system of claim 18 wherein the means for determining further includes 
one of either a means for storing the digit map for a next round of digit collection or a means 
for replacing any existing digit map received by the second end point. 
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